1. Field of the Invention
The present invention relates generally to Digital Television Application Software Environment (DASE) architectures. More specifically, the present invention relates to architectures providing a software bus and interface for routing application programming interface (API) calls between application engines that are used to implement applications broadcasted in Digital TV broadcast streams.
2. Background Art
Digital technology has added a new dimension to traditional television broadcasting by expanding the types of content that may be broadcasted along with standard program content. For example, applications providing e-commerce capability via television may be broadcasted through digital television (DTV) broadcast signals. However, as can be expected, myriad software compatibility problems have accompanied this expansion of content type. In an effort to provide some uniformity, the National Institute of Standards and Technology (NIST) and the Advanced Television Systems Committee (ATSC) have proposed a broadcast standard, called the Digital Television Application Software Environment (DASE), that sets forth various requirements for DTV systems—e.g., requirements for transmitters and receivers of DTV broadcast signals.
The procedure for broadcasting DTV basically begins with a service provider, such as a program station provider, who broadcasts a digital broadcast stream to a receiving unit (also known as, for purposes of this discussion, a “client-side broadcast rendering machine”) situated at a customer's home or other location. The receiving unit, such as a DASE set-top box, detects digital broadcast signals, parses and interprets them, extracts and executes any software application code included in the broadcast, and enables the downloaded applications to display a user interface on a television display.
To effectively run any DASE software applications broadcasted by the service provider, a special type of software environment must be present at the DASE set-top box. This software environment must include application engines to provide the DASE applications or other broadcasted software components with infrastructure services such as the ability to graphically render text in various fonts. Specifically, DASE requires the implementation of two application engines: (1) a procedural application engine (formally referred to as “AEE”), and (2) a declarative application engine (formally known as “PE”).
The software environment must of necessity also include an application programming interface (API) to provide a communications interface between software applications. Currently, a standard is being defined by the ATSC for providing a uniform set of APIs, called DASE infrastructure APIs, that provide the above-mentioned infrastructure services for DASE broadcasting systems. A portion of these APIs must be implemented by the two application engines, the procedural application engine and the declarative application engine. Also, the APIs must allow the procedural application engine and the declarative application engine to communicate data and exchange control. For example, the ATSC standard requires that the procedural application engine be able to execute an application capable of rendering a web page given in HTML 4.0/CSS2 format, a functionality provided by the declarative application engine. The standard also requires that the declarative application engine be able to display HTML pages which contain Java Xlets (the DASE equivalent of applets), a capability provided by the procedural application engine.
Two different architectures exist with respect to the relationship between the procedural application engine and the declarative application engine. In one architecture, the procedural application engine contains the declarative engine; in the other architecture, the declarative engine contains the procedural engine. FIG. 1 shows the first architecture where the procedural application engine contains the declarative engine (hereinafter referred to as the “procedural-outside” architecture). In this architecture, a procedural application engine 12 implements, either directly or through wrappers, the APIs to interface with a software component or DASE application 10 downloaded from a digital broadcast. Any declarative portions of the application (e.g., HTML pages) are rendered by a declarative application engine 14 that resides completely within the bounds of the procedural application engine 12. In addition, note that the architectures can include other components such as a content decoder 16, a font engine 18, and a security module 20. The applications typically reside at least in part in a single piece of client-side hardware 22 such as a set-top box.
FIG. 2 shows the second type of architecture where the declarative application engine contains the procedural application engine (hereinafter referred to as the “declarative-outside” architecture). Here, the declarative application engine 14 provides the APIs to interface with the broadcasted software application 10. Any procedural portions of the application (e.g., Java Xlets) are executed by the procedural application engine 12 which resides completely within the bounds of the declarative application engine 14.
Existing technology does not allow the simultaneous implementation of both the “procedural-outside” and “declarative-outside” architectures, and a manufacturer that develops its products in accordance with one architecture cannot easily modify the product development effort to follow the other architecture. Thus, not knowing which architecture the ATSC standard will commit to, which has technical superiority, or which better fits market needs, manufacturers that commit to one of the two architectures take an enormous risk that their development costs will skyrocket.